…(defer dir immutable, batch flag)

RsyncProject#5 (medium): batch.c didn't record preserve_fileflags, so
--write-batch --fileflags emits an extra word per file in the
file-list stream (XMIT_SAME_FLAGS bit + fileflags word) that
--read-batch wouldn't expect without the matching option.  Added
preserve_fileflags at slot 15 of flag_ptr/flag_name, marked
"protocol 30+, requires varint flags" so the bit-position remains
stable.  Older rsync readers ignore unknown high bits, so this is
backwards-readable; newer readers of an old batch see bit 15
unset and correctly leave preserve_fileflags at 0.

RsyncProject#4 (medium): if a source directory has immutable / append bits in
SAFE_FILEFLAGS (e.g. chflags uchg dir/), set_file_attrs in
recv_generator applied them to the dest dir BEFORE the children
inside the dir were populated -- and the +i then blocked rsync
from creating those children at all.  Pass ATTRS_DELAY_IMMUTABLE
in the recv_generator set_file_attrs call for dirs, mirroring
how finish_transfer already defers immutable bits for temp-then-
rename files.  touch_up_dirs now re-applies the deferred bits
after all children have been processed.

RsyncProject#2 (high): the early `continue` in touch_up_dirs at "no times to
retouch and no perms to fix" skipped the per-directory force_change
restore (undo_make_mutable) too -- so --force-change --omit-dir-times
on a +i source dir was leaving the dest dir permanently mutable.
Same issue would now affect the new --fileflags deferred-apply path
without the fix.  Split the continue condition: never skip if there's
a force_change restore pending OR a deferred --fileflags apply
pending OR the existing times/perms work.

Side effect of the RsyncProject#4 fix: set_fileflags() is no longer static
because the new touch_up_dirs path calls it directly (cleaner
than overloading undo_make_mutable's name).

Testsuite addition: fileflags.test now exercises the deferred-
immutable-on-dir scenario when the test user can set uchg (only on
BSD/macOS or as root on Linux).  Creates a uchg source dir with
children, rsyncs, asserts the children are present AND the dest dir
ends up with uchg set -- which means rsync deferred the bit until
after the children populated.

Verified Linux/ext4 full suite 60 passed / 2 skipped / 0 failed
(the new test block self-skips on non-root Linux since chattr +i
needs CAP_LINUX_IMMUTABLE).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ncProject#6 (chmod mode arg)

These two small syscall.c fixes were made at the start of the round-4
work but got dropped on the floor when I split the commit -- only the
docs (RsyncProject#1) and the bigger RsyncProject#2/RsyncProject#4/RsyncProject#5 deferred-immutable-dir series ended
up landed.  The tree was left dirty.

RsyncProject#3: do_rename (the non-_at variant) was missing the hardlink-aware
restore I added to do_rename_at last round.  Same shape -- when
renameat replaces a destination inode that had st_nlink > 1, the
remaining hardlinks survive carrying the cleared flags.  Restore via
new_fd before close (the fd still refers to the surviving inode).

RsyncProject#6: do_chmod and do_chmod_at force_change recovery were calling
make_mutable_fd(fd, mode, ...) where mode was the caller-supplied
chmod-target mode -- some callers (notably xattrs.c's set_xattr
recovery path) pass perm bits only, no S_IFREG / S_IFDIR, so on Linux
rsync_fchflags rejects the call as neither regular file nor directory
and recovery silently fails.  Use st.st_mode from the freshly-fstatted
target instead, which always has the right S_IFx bits.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>